Cryptography is commonly employed to authenticate data, encode data, or encrypt/decrypt data in a manner that allows the data to be stored and/or transmitted securely. Cryptography is becoming more and more popular as computers and networks increase in number, size and complexity.
By way of example, public/private key pairs are commonly used in computing devices, such as, personal computers (PCs) and the like, to provide asymmetric encryption of data that is exchanged between communicating parties. Asymmetric encryption uses public-key encryption algorithms. Public-key algorithms use two different keys (known as a key pair), namely, a public key and a private key. These two keys are typically derived from extremely large prime numbers making them mathematically related. However, it is practically impossible to derive one key from the other. As suggested by their names, the public key is made public, while the private key is kept private. In a typical static machine concentric PC environment, the private key may never leave the PC on which it was generated.
Information (i.e., data) that is encrypted with either one of the keys can only be decrypted with the other one of the keys. Thus, for example, data encrypted with the private key can only be decrypted with the public key, and vice versa.
As an additional safety measure, a session key may also be used during a communication session. A session key is essentially a temporary private key or secret that is shared between the communicating parties. Upon decrypting the session key the receiving party can decrypt the encrypted data. The integrity of the decrypted message can be verified by hashing the message to produce a message digest, and comparing that digest value to the digest computed by the sender and included in the encrypted message.
One problem associated with such cryptography techniques is that a third party might attempt to masquerade as one of the communicating parties, for example, by fraudulently holding out a public key that is represented to be one of the communicating parties public keys. Any messages or hashes that are intended for the communicating party and encrypted with the fraudulent public key could conceivably be decrypted with the accompanying private key by the third party.
To address this problem and others, a digital certificate can be employed by the communicating parties. A digital certificate is a credential issued by a trusted organization or entity called a certification authority (CA), such as, for example, VeriSign, Inc. This credential typically contains a public key and data that identifies the certificate's subject (i.e., the applicable communicating party). A certificate is usually issued by a CA only after the CA has verified the certificate's subject's identity and has confirmed that the public key included with the certificate belongs to that subject. The certificate may also include a digest of the certificate's contents that is signed with the private key of the CA to ensure that the certificate has not been altered or forged.
A CA may also provide self-signed certificates, or root certificates, that are to be inherently trusted. A CA may itself be certified by a hierarchy of other CAs; such information is usually included within the certificate. When a digital certificate is used to sign documents and software, this information is stored with the signed item in a secure and verifiable form that can be displayed to a user to establish a trust relationship.
Over a period of time, digital certificates will tend to accumulate on a PC. These digital certificates are usually collected in a certificate store. Tools are provided, typically as application programming interface (API) functions that allow the user to store, retrieve, delete, enumerate, verify, or otherwise maintain the digital certificates within the certificate store.
With this in mind, Microsoft Corp. of Redmond, Wash., develops software, operating systems and other applications for use with a variety of “machines”, including general and special purpose computers, PCs, portable devices, and the like. Microsoft Corp. has developed a Cryptographic API (hereinafter, generically referred to as “CryptoAPI”) that provides a controlled/expandable interface between applications seeking cryptographic services and programs/devices that can provide such cryptographic services. Within CryptoAPI tools (e.g., functions) are provided that can be used to manage the digital certificates in the digital store and attach the digital certificates to data files. For example, CryptoAPI maintains a certificate revocation list (CRL) that is typically issued by the CA and lists digital certificates that are no longer valid. CryptoAPI also supports a certificate trust list (CTL) that identifies items that have been signed by a trusted entity. The various digital certificates, CRLs and CTLs within the certificate store are normally kept in non-volatile memory within the machine, such as, for example, a disk file or the system registry.
The cryptographic programs/devices that can provide the requested cryptographic services may include general purpose and/or special purpose hardware/software that is added to the machine and provides the necessary unique cryptographic token. Thus, for example, CryptoAPI allows new/additional cryptography devices/tokens to be added to the machine and acts as an interface between the requesting application(s) and the added cryptographic device/tokens. This type of API functionality/interface is well known and described in greater detail in U.S. Pat. No. 5,689,565, issued Nov. 18, 1997 to Spies et al.
The above-described API functionality/interface tends to work well with static machine concentric tokens, since it basically assumes that the cryptographic device(s) is fixed in place, always available, and used only by the local machine. However, if some of the tokens are portable, then the API functionality/interface will not always be able to locate the needed token(s).
Consequently, with the recent popularity of smart cards (SCs) and other types of portable token carrying and/or removable processing devices, designers have been required to provide some form of interfacing logic that allows a particular SC, etc., to operate with the CryptoAPI. This presented several problems. For example, if a PC or other like computing device needed to be able to support different types of SCs, then it would need to maintain the proper interfacing logic, e.g., software, for each of the of the different SCs. Moreover, as it turned out in many cases, the interfacing logic could be very complex to build and design. For these and other reasons, there is a need for improved methods and apparatuses for operatively coupling portable token mechanisms and/or other like removable/non-removable processing devices to certain cryptography supporting logic within various forms of computing devices and/or appliances.